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DETAILED ACTION 

1 . This office action is in response to Amendment A, paper number 7, which was received 
September 2, 2003. Applicant's arguments have been fully considered but are moot in view of 
the new grounds of rejection. Claims 1-21 are presented for examination. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in pubUc use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. \ 

3. Claim 1 is rejected under 35 U.S.C. 102(b) as being anticipated by Lindholm et al. 
(USPN 5,797,004) (hereinafter Lindholm). 

As per claim 1, Lindholm discloses a system comprising: 

a shared resource (col. 1 lines 30-45, "an object may require access to a shared computer 
resource, such as an I/O device, than can only handle one access at a time"); 

multiple processors arranged to access said shared resource (col. 1 lines 16-29, "In 
multiprocessor computer systems, software programs may be executed by threads that are run in 
parallel on the processors that form the multiprocessor computer system"); and 

an operating system configured to allow said multiple processors to perform work on said 
shared resource concurrently while supporting state changes or updates of said shared resources 
(col. 3 line 54 - col. 4 line 2, "such methods may be explicitly declared synchronized... so that 
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when one is executed by a thread, the object that contains the method will be synchronized with 
and owned by that thread", wherein the state changes for a shared resource correspond to the 
changing between a synchronized and non-synchronized state), said operating system comprising 
a synchronization algorithm for synchronizing multiple threads of operation with a single thread 
so as to achieve mutual exclusion between multiple threads performing work on said shared 
resource and a single thread updating or changing the state of said shared resource without 
requiring serialization of all threads (Fig. 3, wherein the method of a synchronization module 
synchronizing an object with only one thread is depicted) such that an update or change of the 
state of the shared resource may be made by the single thread only when none of the multiple 
threads are processing work on the shared resource (col. 1 1 lines 37-47, "a mutex is locked when 
it is allocated and has its synchronizers list 210 [or synchronizer identifier in the case where only 
one thread can by synchronized with an object] updated to identify the thread that is 
synchronized with an object and unlocked when it is de-allocated"). 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 2-3 and 9-10 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lindholm in view of Spix et al (USPN 5,179,702) (hereinafter Spix). 
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As per claim 2, Spix discloses the following limitations not shown by Lindholm, 
specifically the system as claimed in claim 1, wherein said shared resource includes work queues 
associated with a hardware adapter configured to send and receive message data to/from a 
remote system (col. 15 lines 3-27, "all of the CPU's., .and all of the I/O controllers. . .have access 
to a common set of data structures in the Operating System Shared Resources [OSSR], including 
a Work Request Queue"). 

It would have been obvious to one of ordinary skill in the art to combine Lindholm with 
Spix since the method disclosed in Spix, while disclosing a way of allowing multiple CPUs to 
access shared resources that include work queues, does so according to an 'anarchistic' 
scheduling algorithm, which may be unsuitable for most needs. Thus, the combination with 
Lindholm provides a rigid scheduling algorithm that regulates access to synchronization 
constructs, while utilizing shared resources of particular I/O devices that support work queues, 
such as those associated with network communication. 

As per claim 3, Lindholm discloses the system as claimed in claim 2, wherein said 
synchronization algorithm is executed to synchronize any thread wishing to update or change a 
state of said shared resource with all the threads processing I/O operations on said shared 
resource (col. 6 line 56 - col. 7 line 6, "If the cache manager finally encounters the last 
synchronization construct in the chain and its pointer does not point to another synchronization 
construct, as might be the case with synchronization constructs 124-3, then this means that the 
object 114-2 is not synchronized with any of the threads 116. In this case, the cache manager 



Application/Control Number: 09/539,624 Page 5 

Art Unit: 2127 

allocates the first synchronization construct 124-N in the free list", wherein when a thread 
attempts to lock a resource, the thread is synchronized with all threads in the system that may 
also be trying to lock that resource). 

As per claim 9, Lindholm discloses the system as claimed in claim 2, wherein said 
synchronization algorithm is installed as part of a software driver module of an operation system 
[OS] kernel or an user-level application of said system (col. 3 lines 31-33, "the method employed 
by the object synchronization module...", wherein the synchronization algorithm is implemented 
within a software module). 

As per claim 10, Spix discloses the system as claimed in claim 2, wherein said shared 
resource includes one of work queues, completion queues, FIFO queues, hardware adapters, I/O 
controllers and other memory elements of said system (col. 15 lines 3-27, "all of the 
CPU's.. .and all of the I/O controllers... have access to a common set of data structures in the 
Operating System Shared Resources [OSSR], including a Work Request Queue", wherein a 
FIFO queue is analogous to a work queue since a work queue could be designed as a FIFO as 
well as a LIFO, or any other queue structure). 

Concerning the additional limitations of hardware adapters, I/O controllers, etc. 
Lindholm discloses these as types of shared resources that may require synchronization (col. 1 
lines 30-45, "an object may require access to a shared computer resource, such as an I/O device, 
that can only handle one access at a time. Thus, since concurrently running threads may 
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concurrently seek to invoke a method of an object, the object must be synchronized with only 
one thread at a time"). 

It would have been obvious to one of ordinary skill in the art to combine Lindholm with 
Spix for reasons discussed above in reference to claim 2. 

6. Claims 4-7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Lindholm in 
view of Kerrigan et al. (USPN 5,404,488) (hereinafter Kerrigan). 

As per claim 4, Kerrigan discloses the following limitations not shown by Lindholm, 
specifically the system as claimed in claim 1 , wherein said synchronization algorithm is executed 
to allow worker threads to work concurrently while processing I/O operations in exclusion of an 
update thread when a state of said shared resource is not changing, and allow an update thread to 
change the state or update said shared resource in exclusion of multiple worker threads (col. 24 
lines 28-39, "the update thread sits on buffer access semaphore 3820 of the current buffer 3810 
and waits for it to be cleared. When that semaphore is cleared, the underlying buffer area is 
released to the updater thread so that its messages may be transferred to the master interest list"). 

It would have been obvious to one of ordinary skill in the art to combine Lindholm with 
Kerrigan since Lindholm allows all threads that are synchronized with an object to perform state 
updates on the shared resource. This can lead to excessive context switching and tremendous 
overhead, a situation that requires remedy. Kerrigan discloses a way of updating an application 
using an update thread and a synchronization construct, specifically a semaphore. Although 
Kerrigan is related to updating the data pertaining to an application, the idea is easily combinable 
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with Lindholm since Kerrigan discloses threads and synchronization constructs, as does 
Lindholm. The combination therein would thus allow Lindholm to be satisfactorily modified 
such that only one specific thread performs updates on the shared resource, thereby reducing the 
costly overhead incurred if each thread working on a shared resource updated the status upon 
synchronization or desynchronization. 

As per claim 5, Lindholm discloses the system as claimed in claim 4, wherein said 
synchronization algorithm is executed to support a worker thread operation for processing 
simultaneous I/O operations on said shared resource while concurrently supporting an update 
thread operation for updating or changing the state of said shared resource (col. 1 lines 30-45, 
"an object may require access to a shared computer resource, such as an I/O device, that can only 
handle one access at a time. Thus, since concurrently running threads may concurrently seek to 
invoke a method of an object, the object must be synchronized with only one thread at a time", 
wherein the combination with Kerrigan as discussed in claim 5 provides for an update thread, 
and the synchronization algorithm would thus ensure that worker threads and the update thread 
are synchronized). 

As per claim 6, Lindholm discloses a system as claimed in claim 5, wherein said worked 
thread operation is invoked by one of an event and a user's request, and is performed by: 

determining whether a lock is available (col. 5 lines 7-20, "Since the thread 116-1 is 
seeking to synchronize the object 1 14-2. . .the cache manager determines if it points to any of the 
synchronization constructs"); 



Application/Control Number: 09/539,624 Page 8 

Art Unit: 2127 

if the lock is not available, waiting until the lock becomes available (col 6 lines 22-34, 
"each synchronization construct 124 includes a waiters list 214 which identifies those of the 
threads 116 that are waiting to synchronize an object that is already synchronized by the 
synchronization construct with the predefined number of threads that can be synchronized with 
the object"); 

if the lock is available, seizing the lock while incrementing a count by a discrete constant 
to indicate the number of worker threads that are active, and then releasing the lock after the 
count has been incremented (col. 11 line 65 - col. 12 line 3, "In the case where the 
synchronization constructs 124 are semiphores, the predefined number of threads 116 that may 
be synchronized with one of the objects 114 at one time may be N", wherein as each thread is 
allocated to the synchronization construct the counter is incremented, so long as the value 
remains below N); 

after the lock has been released, allowing multiple worker threads to process work 
concurrently (col. 3 line 55 - col. 7 line 20, wherein once the threads have been allocated to the 
synchronization construct, they concurrently execute on the resource); 

determining next whether there is work to be processed (col. 7 lines 23-29, "When the 
synchronization method 200 of one of the objects 114, such as object 114-2, is terminated, 
synchronization of the object with whichever of the threads 116, such as 1 16-1, is completed"); 

if there is work to be processed, processing the work until there is no work to be 
processed (col. 7 lines 23-29, "When the synchronization method 200 of one of the objects 1 14, 
such as object 114-2, is terminated, synchronization of the object with whichever of the threads 
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116, such as 1 16-1, is completed", wherein execution continues until the method has completed); 
and 

if there is no work to be processed, decrementing the count by a discrete constant to 
indicate when all the worker threads are done with completion processing (col. 7 line 47 - col. 8 
line 19, "if there are no more threads in the synchronizers list, the cache manager deallocates the 
synchronization construct allocated to the object", wherein as each thread releases the resources 
the synchronizers list is updated, until a determination is made that there are no more threads 
working on the resource). 

As per claim 7, Lindholm discloses a system as claimed in claim 6, wherein said update 
thread operation is invoked by a user's request, and is performed by: 

determining whether a lock is available (col. 5 lines 7-20, "Since the thread 116-1 is 
seeking to synchronize the object 114-2.. .the cache manager determines if it points to any of the 
synchronization constructs"); 

if the lock is not available, waiting until the lock becomes available when released by any 
one of the worker threads (col. 6 lines 22-34, "each synchronization construct 124 includes a 
waiters list 214 which identifies those of the threads 116 that are waiting to synchronize an 
object that is ah*eady synchronized by the synchronization construct with the predefined number 
of threads that can be synchronized with the object"); 

if the lock is available, seizing the lock until the count becomes zero (0) to indicate that it 
is safe to update or change the state of said shared resource, and updating or changing the state of 
said shared resource (col 7 line 63 - col. 8 line 19, "if there are no more threads in the 
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synchronizers list, the cache manager deallocates the synchronization construct. ..by updating the 
pointer of the deallocated synchronization construct... and updating the free list header"); and 

after said shared resource has been updated, releasing the lock so as to allow either new 
worker threads to continue I/O operation processing or a different update thread to continue 
shared resource updating (col. 7 line 63 - col. 8 Une 19, "if there are no more threads in the 
synchronizers list, the cache manager deallocates the synchronization construct... by updating the 
pointer of the deallocated synchronization construct... and updating the free list header", wherein 
updating the free list header tells the synchronization module that other threads may use the 
synchronization construct). 

7, Claims 8, 11-12, and 17-19 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lindholm in view of Spix in view of Tillier (previously cited). 

As per claim 8, Tillier discloses the following limitations not shown by the modified 
Lindholm, specifically a system as claimed in claim 2, further comprising data channels formed 
between said system and said remote system, via a switched fabric, and supported by the 
''Virtual Interface [VI] Architecture Specification'' and the ''Next Generation Input/Output 
[NGIOJ Specification'' for message data transfers between said system and said remote system 
(col. 5 lines 14-36, "The example embodiment and other embodiments of the invention can be 
implemented in conjunction with other types of switch fabric-based I/O architectures. The 
example embodiment NGIO uses a similar model for input/output data transfer as is specified by 
the VI architecture"). 
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It would have been obvious to one of ordinary skill in the art to combine the modified 
Lindholm with Tillier since the modified Lindholm only speaks to synchronization of threads in 
a multiprocessor system, but does not necessarily account for other types of networks, such as a 
switched fabric network. Tillier discloses a way of implementing such systems and thus would 
allow the modified Lindholm to be implemented on a wider variety of systems. 

As per claim 11, Lindholm discloses an operating system configured to allow said 
multiple processors to perform work on said shared resource concurrently while supporting state 
changes said shared resources (col. 3 line 54 - col. 4 line 2, "such methods may be explicitly 
declared synchronized... so that when one is executed by a thread, the object that contains the 
method will be synchronized with and owned by that thread", wherein the state changes for a 
shared resource correspond to the changing between a synchronized and non-synchronized state), 
said operating system comprising a synchronization algorithm for synchronizing multiple threads 
of operation with a single thread so as to achieve mutual exclusion between muUiple threads 
performing work on said shared resource and a single thread changing the state of said shared 
resource without requiring serialization of all threads (Fig. 3, wherein the method of a 
synchronization module synchronizing an object with only one thread is depicted) such that an 
update or change of the state of the shared resource may be made by the single thread only when 
none of the multiple threads are processing work on the shared resource (col 1 1 lines 37-47, "a 
mutex is locked when it is allocated and has its synchronizers list 210 [or synchronizer identifier 
in the case where only one thread can by synchronized with an object] updated to identify the 
thread that is synchronized with an object and unlocked when it is de-allocated"). 
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Spix discloses the following limitations not shown by Lindholm, specifically that the 
shared resources may be work queues (col. 15 lines 3-27, "all of the CPU's... and all of the I/O 
controllers... have access to a common set of data structures in the Operating System Shared 
Resources [OSSR], including a Work Request Queue"). 

It would have been obvious to one of ordinary skill in the art to combine Lindholm with 
Spix since the method disclosed in Spix, while disclosing a way of allowing multiple CPUs to 
access shared resources that include work queues, does so according to an 'anarchistic' 
scheduling algorithm, which may be unsuitable for most needs. Thus, the combination with 
Lindholm provides a rigid scheduling algorithm that regulates access to synchronization 
constructs, while utilizing shared resources of particular I/O devices that support work queues, 
such as those associated with network communication. 

Tillier discloses the following limitations not shown by the modified Lindholm, 
specifically a network, comprising: 

a switched fabric (col 5 lines 14-36, "The example embodiment and other embodiments 
of the invention can be implemented in conjunction with other types of switch fabric-based I/O 
architectures"); 

remote systems attached to said switched fabric (col. 2 lines 20-40, "The present 
invention is directed to emulation in an I/O unit when transferring data over a network" wherein 
it is inherent that a network would comprise remote systems); and 

a host system comprising multiple processors; a host-fabric adapter provided to interface 
with said switched fabric and included work queues each configured to send and receive message 
data from a single remote system, via said switched fabric (fig. 1 element 101 - I2O Host). 
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It would have been obvious to one of ordinary skill in the art to combine the modified 
Lindholm with Tiller since the modified Lindholm only speaks to synchronization of threads in a 
multiprocessor system, but does not necessarily account for other types of networks, such as a 
switched fabric network. Tillier discloses a way of implementing such systems and thus would 
allow the synchronization algorithm disclosed by Lindholm to be implemented on a wider 
variety of systems. 

As per claim 12, Lindholm discloses the network as claimed in claim 11, wherein said 
synchronization algorithm is executed to synchronize any thread wishing to update or change a 
state or said work queues with all the threads processing I/O operations on said work queues 
(col 6 line 56 - col. 7 line 6, "If the cache manager finally encounters the last synchronization 
construct in the chain and its pointer does not point to another synchronization construct, as 
might be the case with synchronization constructs 124-3, then this means that the object 1 14-2 is 
not synchronized with any of the threads 116. In this case, the cache manager allocates the first 
synchronization construct 124-N in the free list", wherein when a thread attempts to lock a 
resource, the thread is synchronized with all threads in the system that may also be trying to lock 
that resource). 

As per claim 17, Tillier discloses the following limitations not shown by the modified 
Lindholm, specifically a network as claimed in claim 11, further comprising data channels 
formed between said system and said remote system, via said switched fabric, and supported by 
the ''Virtual Interface [VI] Architecture Specification'' and the ''Next Generation Input/Output 
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[NGIO] Specification'' for message data transfers between said host system and said remote 
systems (col 5 lines 14-36, "The example embodiment and other embodiments of the invention 
can be implemented in conjunction with other types of switch fabric-based I/O architectures. 
The example embodiment NGIO uses a similar model for input/output data transfer as is 
specified by the VI architecture"). 

It would have been obvious to one of ordinary skill in the art to combine the modified 
Lindholm with Tillier for reasons discussed above in reference to claim 1 1 . 

As per claim 18, Lindholm discloses the network as claimed in claim 11, wherein said 
synchronization algorithm is installed as part of a software driver module of an operating system 
[OS] kernel or an user-level application of said host system (col. 3 lines 31-33, "the method 
employed by the object synchronization module...", wherein the synchronization algorithm is 
implemented within a software module). 

As per claim 19, Tillier discloses the network as claimed in claim 1 1, wherein said host 
system and said remote systems represent channel endpoints of a data network implemented in 
compliance with the ''Next Generation Input/Output [NGIO] Specification"", and data channels 
formed between said host system and said remote systems, via said switched fabric, are 
supported by the ''Virtual Interface [VI] Architecture Specification'' and the "Next Generation 
Input/Output [NGIO] Specification" for message data transfers between said host system and 
said remote systems (col. 5 lines 14-36, "The example embodiment and other embodiments of 
the invention can be implemented in conjunction with other types of switch fabric-based I/O 
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architectures. The example embodiment NGIO uses a similar model for input/output data 
transfer as is specified by the VI architecture", wherein the use of NGIO and VI architectures are 
meant example embodiments of switched fabric architectures that can be used, and support I/O 
messaging across networks). 

It would have been obvious to one of ordinary skill in the art to combine the modified 
Lindholm with Tillier for reasons discussed above in reference to claim 11. 

8. Claims 13-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Lindholm 
in view of Spix in view of Tillier in view of Kerrigan. 

As per claim 13, Kerrigan discloses the following limitations not shown by the modified 
Lindholm, specifically the network as claimed in claim 11, wherein said synchronization 
algorithm is executed to allow worker threads to work concurrently while processing I/O 
operations in exclusion of an update thread when the state of said work queues is not changing, 
and allow an update thread to change the state or update said work queues in exclusion of 
multiple worker threads (col 24 lines 28-39, "the update thread sits on buffer access semaphore 
3820 of the. current buffer 3810 and waits for it to be cleared. When that semaphore is cleared, 
the underlying buffer area is released to the updater thread so that its messages may be 
transferred to the master interest list"). 

It would have been obvious to one of ordinary skill in the art to combine the modified 
Lindholm with Kerrigan since the modified Lindholm allows all threads that are synchronized 
with an object to perform state updates on the shared resource. This can lead to excessive 
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context switching and tremendous overhead, a situation that requires remedy. Kerrigan discloses 
a way of updating an application using an update thread and a synchronization construct, 
specifically a semaphore. Although Kerrigan is related to updating the data pertaining to an 
application, the idea is easily combinable with Lindholm since Kerrigan discloses threads and 
synchronization constructs, as does Lindholm. The combination therein would thus allow 
Lindholm to be satisfactorily modified such that only one specific thread performs updates on the 
shared resource, thereby reducing the costly overhead incurred if each thread working on a 
shared resource updated the status upon synchronization or desynchronization. 

As per claim 14, Lindholm discloses the network as claimed in claim 11, wherein said 
synchronization algorithm is executed to support a worker thread operation for processing 
simultaneous I/O operations on said work queues while concurrently supporting an update thread 
operation for updating or changing the state of said work queues (col. 1 lines 30-45, "an object 
may require access to a shared computer resource, such as an I/O device, that can only handle 
one access at a time. Thus, since concurrently running threads may concurrently seek to invoke 
a method of an object, the object must be synchronized with only one thread at a time", wherein 
the combination with Kerrigan as discussed in claim 5 provides for an update thread, and the 
synchronization algorithm would thus ensure that worker threads and the update thread are 
synchronized, and Spix provides that the shared resources may be work queues). 

As per claim 15, Lindholm discloses a network as claimed in claim 14, wherein said 
worker thread operation is invoked by one of an event and a user's request, and is performed by: 
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determining whether a lock is available (col. 5 lines 7-20, "Since the thread 116-1 is 
seeking to synchronize the object 1 14-2. . .the cache manager determines if it points to any of the 
synchronization constructs"); 

if the lock is not available, waiting until the lock becomes available (col 6 lines 22-34, 
"each synchronization construct 124 includes a waiters list 214 which identifies those of the 
threads 116 that are waiting to synchronize an object that is already synchronized by the 
synchronization construct with the predefined number of threads that can be synchronized with 
the object"); 

if the lock is available, seizing the lock while incrementing a count by a discrete constant 
to indicate the number of worker threads that are active, and then releasing the lock after the 
count has been incremented (col 11 line 65 - col 12 line 3, "In the case where the 
synchronization constructs 124 are semiphores, the predefined number of threads 116 that may 
be synchronized with one of the objects 114 at one time may be N", wherein as each thread is 
allocated to the synchronization construct the counter is incremented, so long as the value 
remains below N); 

after the lock has been released, allowing multiple worker threads to process work 
concurrently (col 3 line 55 - col 7 line 20, wherein once the threads have been allocated to the 
synchronization construct, they concurrently execute on the resource); 

determining next whether there is work to be processed (col 7 lines 23-29, "When the 
synchronization method 200 of one of the objects 114, such as object 114-2, is terminated, 
synchronization of the object with whichever of the threads 1 16, such as 1 16-1, is completed"); 
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if there is work to be processed, processing the work until there is no work to be 
processed (col. 7 lines 23-29, "When the synchronization method 200 of one of the objects 1 14, 
such as object 114-2, is terminated, synchronization of the object with whichever of the threads 
116, such as 1 16-1, is completed", wherein execution continues until the method has completed); 
and 

if there is no work to be processed, decrementing the count by a discrete constant to 
indicate when all the worker threads are done with completion processing (col. 7 line 47 - col. 8 
line 19, "if there are no more threads in the synchronizers list, the cache manager deallocates the 
synchronization construct allocated to the object", wherein as each thread releases the resources 
the synchronizers list is updated, until a determination is made that there are no more threads 
working on the resource). 

As per claim 16, Lindholm discloses a network as claimed in claim 6, wherein said 
update thread operation is invoked by a user's request, and is performed by: 

determining whether a lock is available (col. 5 lines 7-20, "Since the thread 116-1 is 
seeking to synchronize the object 114-2.. .the cache manager determines if it points to any of the 
synchronization constructs"); 

if the lock is not available, waiting until the lock becomes available when released by any 
one of the worker threads (col. 6 lines 22-34, "each synchronization construct 124 includes a 
waiters list 214 which identifies those of the threads 116 that are waiting to synchronize an 
object that is akeady synchronized by the synchronization construct with the predefined number 
of threads that can be synchronized with the object"); 
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if the lock is available, seizing the lock until the count becomes zero (0) to indicate that it 
is safe to update or change the state of said shared resource, and updating or changing the state of 
said shared resource (col. 7 hne 63 - col 8 Une 19, "if there are no more threads in the 
synchronizers list, the cache manager deallocates the synchronization construct... by updating the 
pointer of the deallocated synchronization construct. ..and updating the free list header"); and 

after said shared resource has been updated, releasing the lock so as to allow either new 
worker threads to continue I/O operation processing or a different update thread to continue 
shared resource updating (col. 7 line 63 - col. 8 line 19, "if there are no more threads in the 
synchronizers list, the cache manager deallocates the synchronization construct... by updating the 
pointer of the deallocated synchronization construct. ..and updating the free list header", wherein 
updating the free list header tells the synchronization module that other threads may use the 
synchronization construct). 

9. Claims 20-21 are rejected under 35 U.S.C. 103(a) as being unpatentable over Lindholm 
in view of Spix in view of Kerrigan. 

As per claim 20, Lindholm discloses a process of synchronizing an update thread which 
updates a list of shared resources with multiple worker threads which operate on items in the list 
of shared resources in a multiprocessor system, comprising: 

allowing a group of worker threads to concurrently access the list of shared resources to 
process I/O operations in mutual exclusion, when states of the work queues are not changing 
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(Fig. 3, wherein the method of a synchronization module synchronizing an object with only one 
thread is depicted); 

incrementing a count of threads processing I/O operations each time a worker thread is 
running (col. 11 line 65 - col. 12 line 3, "In the case where the synchronization constructs 124 
are semiphores, the predefined number of threads 1 16 that may be synchronized with one of the 
objects 114 at one time may be N", wherein as each thread is allocated to the synchronization 
construct the counter is incremented, so long as the value remains below N), while decrementing 
the count of threads processing I/O operations each time a worker thread is done processing I/O 
operations (col. 7 line 47 - col. 8 line 19, "if there are no more threads in the synchronizers list, 
the cache manager deallocates the synchronization construct allocated to the object", wherein as 
each thread releases the resources the synchronizers list is updated, until a determination is made 
that there are no more threads working on the resource); 

when the count of threads reaches a designated value indicating that no worker threads 
are running, allowing an update to access and update the list of shared resources in exclusion of 
new worker threads from processing I/O operations (col. 7 line 63 - col. 8 line 19, "if there are no 
more threads in the synchronizers list, the cache manager deallocates the synchronization 
construct... by updating the pointer of the deallocated synchronization construct. ..and updating 
the free list header"); and 

after the list of shared resources is updated, allowing new worker threads to perform I/O 
operations until all worker threads are done processing I/O operations (col. 7 line 63 - col. 8 line 
19, "if there are no more threads in the synchronizers list, the cache manager deallocates the 
synchronization construct... by updating the pointer of the deallocated synchronization 



Application/Control Number: 09/539,624 Page 2 1 

Art Unit: 2127 

construct... and updating the free list header", wherein updating the free list header tells the 
synchronization module that other threads may use the synchronization construct). 

Spix discloses the following limitations not shown by Lindholm, specifically that the 
shared resources may be work queues (col. 15 lines 3-27, "all of the CPU's... and all of the I/O 
controllers... have access to a common set of data structures in the Operating System Shared 
Resources [OSSR], including a Work Request Queue")- 

It would have been obvious to one of ordinary skill in the art to combine Lindholm with 
Spix since the method disclosed in Spix, while disclosing a way of allowing multiple CPUs to 
access shared resources that include work queues, does so according to an 'anarchistic' 
scheduling algorithm, which may be unsuitable for most needs. Thus, the combination with 
Lindholm provides a rigid scheduling algorithm that regulates access to synchronization 
constructs, while utilizing shared resources of particular I/O devices that support work queues, 
such as those associated with network communication. 

Kerrigan discloses the following limitations not shown by the modified Lindholm, 
specifically that updating the work queues should be done using an update thread (col. 24 lines 
28-39, "the update thread sits on buffer access semaphore 3820 of the current buffer 3810 and 
waits for it to be cleared. When that semaphore is cleared, the underlying buffer area is released 
to the updater thread so that its messages may be transferred to the master interest list"). 

It would have been obvious to one of ordinary skill in the art to combine the modified 
Lindholm with Kerrigan since the modified Lindholm allows all threads that are synchronized 
with an object to perform state updates on the shared resource. This can lead to excessive 
context switching and tremendous overhead, a situation that requires remedy. Kerrigan discloses 
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a way of updating an application using an update thread and a synchronization construct, 
specifically a semaphore. Although Kerrigan is related to updating the data pertaining to an 
application, the idea is easily combinable with Lindholm since Kerrigan discloses threads and 
synchronization constructs, as does Lindholm. The combination therein would thus allow 
Lindholm to be satisfactorily modified such that only one specific thread performs updates on the 
shared resource, thereby reducing the costly overhead incurred if each thread working on a 
shared resource updated the status upon synchronization or desynchronization. 

As per claim 21, the modified Lindholm discloses a computer readable medium that 
stores computer executable instructions for implementing the process of claim 20. Specifically, 
since Lindholm discloses that the synchronization method should be implemented as a software 
module, the method inherently must reside on a computer readable medium that stores computer 
executable instructions in order to be functional. 

Conclusion 

10. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Syed J Ali whose telephone number is (703) 305-8106. The 
examiner can normally be reached on Mon-Fri 8-5:30, 2nd Friday off. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William A Grant can be reached on (703) 308-1 108. The fax phone number for the 
organization where this application or proceeding is assigned is (703) 872-9306. 
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Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is (703) 305-3900. 

Syed Ali 

November 4, 2003 
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